Mostly surface-level concerns. The implementation is otherwise very good, and I'm more than happy to merge this once my issues are addressed.

Last concern.

done

Surface level review, but I have some big concerns:

1. HudTextLine being instantiated dozens of times each frame.
2. Vanilla debug renderer being completely skipped.

In my opinion, HudTextLine should instead contain a template string and an array of callbacks for formatting, so that it can be instantiated once and always be up-to-date.

For example: Template "Used memory: %d\% (%dMB) of %dMB", the array of callbacks being:

var callbacks = new Supplier[] {
  () -> (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) * 100L / Runtime.getRuntime().maxMemory(),
  () -> (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) / 1024L / 1024L,
  () -> Runtime.getRuntime().maxMemory() / 1024L / 1024L
}

This is just a working example, this could be optimized by using a single class with its methods registered as callbacks, so the calculated values could be shared.

Making HudTextLine use callbacks also enables the debug HUD to just be built once instead of each frame.

As for the vanilla lines being completely canceled, I feel like a more surgical approach must be taken where there's a way to cancel each line (maybe by using something like EnumSet<VanillaHudLine> canceled?) and then overwrite the freed space while building the debug HUD. StAPI shouldn't have to render Minecraft's debug if it's unchanged.

Wrong PR lmao, I should look at my tabs.